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DETAILED ACTION 

1. This office action is in response to the Application 10/589,595 filed 
08/25/2006. 

2. Claims 1-39 are pending in the Application. 

Specification 

3. Applicant is reminded of the proper language and format for an abstract of the 
disclosure. 

The abstract should be in narrative form and generally limited to a single paragraph on 
a separate sheet within the range of 50 to 150 words. It is important that the abstract 
not exceed 150 words in length since the space provided for the abstract on the 
computer tape used by the printer is limited. The form and legal phraseology often used 
in patent claims, such as "means" and "said," should be avoided. The abstract should 
describe the disclosure sufficiently to assist readers in deciding whether there is a need 
for consulting the full patent text for details. 

The language should be clear and concise and should not repeat information 
given in the title. It should avoid using phrases which can be implied, such as, "The 
disclosure concerns," "The disclosure defined by this invention," "The disclosure 
describes," etc. 

4. The title of the invention is not descriptive. A new title is required that is 
clearly indicative of the invention to which the claims are directed. 

5. The disclosure is objected to because of the following informalities: numerous 
grammatical errors are found in the instant Specification, for example "data are" should 
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be replaced by -data is-- (paragraphs [0050], [0099], [0101], [0189] of the Patent 
Application Publication of the instant Specification). 
Appropriate correction is required. 

Claim Objections 

6. Claim 1 is objected to because of the following informalities: 
Claim 1 line 2 after "block;" delete "and" 

Appropriate correction is required. 

Claim Rejections - 35 USC §112 

7. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

8. Claims 1-39 are rejected under 35 U.S.C. 112, second paragraph, as being 
incomplete for omitting essential structural cooperative relationships of elements, such 
omission amounting to a gap between the necessary structural connections. See 
MPEP § 2172.01. The omitted structural cooperative relationships are: claims 1,11 and 
26 are formulated unclear to what Applicant intent to mean, such as it is not clear where 
hardware block and software block are arranged. Therefore relationships between 
limitations are indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. 

Claim Rejections - 35 USC § 101 

9. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 
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10. Claims11-39 are rejected under 35 U.S. C. 101 because the claimed 
invention is directed to non-statutory subject matter. 

The claims 11 and 26 are directed to a judicial exception; as such, pursuant to 
the Interim Guidelines on Patent Eligible Subject Matter (MPEP 2106), the claims must 
have either physical transformation and/or a useful, concrete and tangible result. The 
claims fail to include transformation from one physical state to another. Although, the 
claims appear useful and concrete, there does not appear to be a tangible result 
claimed. Merely applying the valid output data of the software block to the hardware 
block would not appear to be sufficient to constitute a tangible result, since the outcome 
of the applying the valid output data of the software block to the hardware block step 
has not been used in a disclosed practical application nor claimed as made available in 
such a manner that its usefulness in a disclosed practical application can be realized. 
As such, the subject matter of the claims is not patent eligible. 

Claim Rejections - 35 USC § 102 

1 1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 
that form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

12. Claims 1, 11, 26 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Park et al. (US Patent 7,185,295). 



Application/Control Number: 10/589,595 Page 5 

Art Unit: 2825 

With respect to claim 1 (as best understood) Park et al. teaches a chip design 
verification apparatus (within chip testing apparatus shown on the Fig. 2 (col. 5, II. 29-30; 
abstract)), comprising: 

at least one hardware block (within target shown on the Fig. 2 including hardware 
blocks (col. 5, II. 49-53)); and 

a processing means including at least one software block of performing data 
communication with the hardware block, and verifying an operation between the 
hardware block and the software block (within target matching process to enable the 
hardware model and the software model of the target to show the same result as the 
simulation result by using the test vector before performing a verification of the target 
(col. 17, 11.19-24), wherein the test vector is applied to the target and the output data 
from target is compared with expected data as step 250 shown on the Fig. 14a (col. 17, 
II.48-52)), the processing means including, 

an interface means of transmitting output data of the hardware block, determining 
whether the output data of the software block is valid, and applying only the valid output 
data of the software block to the hardware block (within interface 32 shown on the Fig. 
2, which transmits the test vector to the target 34 and transmits the result back to the 
testing program 30 (col. 17, 11.49-51) and when the input data is consistent with 
expected data (i.e. valid data) is kept as shown by step 370 of the Fig. 14a (col. 17, 
II.55-56; II.33-36)); 

a storage means of storing a software block and a chip design verification 
program for verifying the software block (within hard disk 22 shown on the Fig. 1 
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presenting a computer system for implementation of the verification process of the chip 
design, wherein hard disk 22 of the mainframe 2 (Fig. 2) stores testing program 30 (Fig. 

2) including various of input/output data (col. 5, II.36-38; 11.10-12)); and 

a controller of transmitting the output data of the software block generated by the 
operation of executing the chip design verification program to the interface means, 
determining whether the output data of the hardware block input via the interface means 
is valid, and applying only the valid output data of the hardware block to the software 
block (within controller of the interface 32 shown on the Fig. 5 (col. 6, II. 55-56; II. 3-6), 
wherein interface 32 implements applying a signal to the target 34 (hardware block) and 
storing a signal applied from the target 34 /hardware block (col. 8, 11.31-33), wherein 
chip testing program runs by a normal termination of an operation when the last frame is 
completely transmitted/valid/kept in step 370 of the Fig. 14a (col. 17, II. 55-56; col. 7, 11.1- 

3) ). 

With respect to claim 11 (as best understood) Park et al. teaches the limitations 
similar to claim 1 including a chip verification method for a chip design verification 
apparatus including et least one hardware block and a processing means, the 
processing means having at least one software block, a chip design verification 
program, and storage means of storing input and output data, and interface means of 
interfacing with the software block and the hardware block (abstract, title). 

With respect to claim 26 (as best understood) Park et al. teaches a chip design 
verification method for a chip design verification apparatus including a hardware block 
and a software block having at least one function block, a chip design verification 
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program for verifying operations of the software block and the hardware block, a storage 
means of storing input and output data of the software block generated by executing the 
chip design verification program, and an interface means of performing an interfacing 
operation between the hardware block and the software block (abstract, title), the 
method comprising: 

a clock generation step of allowing the chip design verification program to obtain 
a multi clock setting value to be provided to the interface means, and generate multi 
clocks in response to a system clock of the chip design verification program and the 
multi clock setting value to be applied to the software block, and allowing the interface 
means to generate multi clocks in response to the system clock of the interface means 
and the multi clock setting value to be applied to the hardware block (within clock 
controller 66 shown on the Fig. 5, which is a controller of the interface 32 and generates 
clock signals of the interface 32 (col. 7, II. 59-62), which is in conjunction with controller 
64 performs verification/matching step between hardware block/target 34 and software 
block using interface 32 (col. 18, 11.12-21)); 

a software side operation step of transmitting output data generated by the 
operation of the software block operating in response to the multi clocks of the chip 
design verification program to the interface means, determining whether the output data 
of the hardware block received via the interface means is valid by executing the chip 
design verification program, and applying only the valid output data of the hardware 
block to the software block (by applying multiple clock signals to the target 34 (col. 18, 
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11.18-21) and storing data outputted from the target 34 for analysis (col. 18, II. 38-43) and 
for further determination error identification (col. 18, II.49-50)); and 

a hardware side operation step of transmitting output data generated by the 
operation of the hardware block operating in response to the multi clocks of the 
interface means to the software block, determining whether the output data of the 
software block received is valid by executing the chip design verification program in the 
interface means, and applying only the valid output data of the software block to the 
hardware block (by applying multiple clock signals to the target 34 (col. 18, 11.18-21) and 
storing data outputted from the target 34 for analysis (col. 18, II. 38-43) and for further 
determination error identification (col. 18, II.49-50; 11.51-60)). 

With respect to claims 2-10, 12-25 and 27-39 Park et al. teaches 

Claim 2: wherein the chip design verification program has a graphic user 
interface, and allows data transceived by executing the chip design verification program 
to be displayed via the graphic user interface (col. 4, II. 23-25; col. 7, II. 24-47; Fig. 9); 

Claims 3, 12: wherein the chip design verification program obtains a multi clock 
setting value for operating the software block and the hardware block, and stores the 
value in the interface means (col. 7, II.59-62; col. 18, 11.12-21); 

Claims 4, 12: wherein the interface means has a clock controller of generating 
multi clocks in response to the multi clock setting value and a system clock of the 
interface means and applying the multi clocks to the hardware block (col. 18, 11.12-21); 

Claims 5, 13, 27: wherein the output data of the hardware block has an output 
value of the hardware block changed in response to the multi clocks applied from the 
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interface means, and a system clock count value of the interface means when the 
output value of the hardware block is changed (col. 18, II.44-50; II. 54-57); 

Claims 6, 14, 28: wherein the valid output data of the hardware block is an output 
value of the hardware block when the system clock count value of the interface means 
is equal to or smaller than the system clock count value of the chip design verification 
program, and is an output value of the hardware block when the output value of the 
software block is not changed even when the system clock count value of the chip 
design verification program is increased so as to be equal to the system clock count 
value of the interface means after determination that the system clock count value of the 
interface means is greater than the system clock count value of the chip design 
verification program (col. 19, 11.19-21; col. 22, 11.10-19); 

Claim 7: wherein the chip design verification program generates multi clocks in 
response to the multi clock setting value and the system clock of the chip design 
verification program to apply the multi clock to the software block (col. 7, II. 43-47; col. 
18, 11.18-21); 

Claims 8, 15, 29: wherein output data of the software block has an output value 
of the software block changed in response to the multi clocks applied from the chip 
design verification program, and a system clock count value of the chip design 
verification program when the output value of the software block is changed (col. 18, 
11.51-51-52; II.58-60); 

Claims 9, 16, 30: wherein the valid output data of the software block is an output 
value of the software block when the system clock count value of the chip design 
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verification program is equal to or smaller than the system clock count value of the 
interface means, and is an output value of the software block when the output value of 
the hardware block is not changed even when the system clock count value of the 
interface means is increased so as to be equal to the system clock value of the chip 
design verification program after determination that the system clock count value of the 
chip design verification program is greater than the system clock count value of the 
interface means (col. 7, II. 33-48); 

Claims 10, 22, 36: wherein the software block has a test-bench, and the test- 
bench supplies the multi clock setting value to the chip design verification program and 
operates in response to the multi clocks of the chip design verification program instead 
of the multi clocks owned by the test-bench itself (col. 14, II. 27-33); 

Claims 17, 23, 31 , 37: wherein the software side operation step includes: 

a step of initiating an operation of receiving output data of the hardware via the 
interface means by executing the chip design verification program (col. 14, II. 59-63); 

a step of confirming that the valid output data of the hardware block is received 
and inputting the output data to the software block, when the received system clock 
count value of the interface means is equal to or smaller than the system clock count 
value of the chip design verification program, or when the output value of the software 
block is not changed even when the received system clock count value of the interface 
means is greater than the system clock count value of the chip design verification 
program to cause the system clock count value of the chip design verification program 
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to be increased so as to be equal to the received system clock count value of the 
interface means (col. 7, II. 33-48); 

a step of transmitting the output data of the software block to the interface means 
when the output value of the software block is changed before the system clock count 
value of the chip design verification program is increased so as to be equal to the 
received system clock count value of the interface means (col. 7, II.43-47; col. 22, 11.13- 
15); and 

a step of initializing the increased system clock count value of the chip design 
verification program when the input step or the transmission step is completed, and 
increasing the system clock count value of the chip design verification program while 
monitoring whether the output value of the software block is changed (col. 22, 11.16-19); 

Claims18, 24, 32, 38: wherein the input step includes: 

a step of inputting the received output value of the hardware block to the 
software block as the valid output data of the hardware block when the received system 
clock count value of the interface means is equal to or smaller than the system clock 
count value of the chip design verification program (col. 17, II.55-56); 

a step of increasing the system clock count value of the chip design verification 
program while confirming whether the output value of the software block is changed 
when the received system clock count value of the interface means is greater than the 
system clock count value of the chip design verification program (col. 22, 11.16-19); and 

a step of inputting the received output value of the hardware block to the 
software block as the valid output data of the hardware block when the output value of 
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the software block is not changed until the increased system clock count value of the 
chip design verification program is greater than the received system clock count value 
of the interface means (col. 22, 11.16-19); 

Claim 19, 33, 35: wherein the input step further includes: a step of displaying the 
valid output data of the hardware block by executing the chip design verification 
program (col. 7, II. 34-40); 

Claims 20, 25, 34, 39: wherein the transmission step includes: 

a step of increasing the system clock count value of the chip design verification 
program while confirming whether the output value of the software block is changed, 
when the received system clock count value of the interface means is greater than the 
system clock count value of the chip design verification program (col. 22, 11.16-19); and 

a step of transmitting the output data of the software block to the interface means 
when the output value of the software block is changed in the case that the increased 
system clock count value of the chip design verification program is equal to or smaller 
than the received system clock count value of the interface means (col. 22, 11.16-19); 

Claim 21 : wherein the transmission step further includes: a step of displaying the 
valid output data of the software block by executing the chip design verification program 
(col. 7, II. 34-37); 

13. Claims 1-39 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Schubert et al. (US Patent 7,240,303). 
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With respect to claim 1 (as best understood) Schubert et al. teaches a chip 
design verification apparatus (within a hardware debugging system for debugging an 
electronic system including electronic circuit design (col. 7, II.46-48)), comprising: 

at least one hardware block (within electronic system 104 shown on the Fig. 20 
including device under test 102 (col. 13, 11.8-10; 11.17-19; col. 56, II.53-55)); and 

a processing means including at least one software block of performing data 
communication with the hardware block, and verifying an operation between the 
hardware block and the software block (within hardware/software debugging system 
2000 and 2100 shown on the Figs. 20 and 21, wherein debugging/verification is 
performed for software 2002 and hardware DUT 102 (col. 56, II. 59-63), wherein 
communication links 2106, 2108 transmit communication data between software block 
and hardware block as shown on the Fig. 21 (col. 57, II.43-48)), the processing means 
including, 

an interface means of transmitting output data of the hardware block, determining 
whether the output data of the software block is valid, and applying only the valid output 
data of the software block to the hardware block (within user interface 2116 shown on 
the Figs. 21, 33B (col. 58, 11.15-55; col. 59, 11.10-14; col. 9, II.22-25)); 

a storage means of storing a software block and a chip design verification 
program for verifying the software block (within a design instrumentation database 114 
shown on the Fig. 20 (col. 12, II.47-48; col. 56, II.53-56)); and 

a controller of transmitting the output data of the software block generated by the 
operation of executing the chip design verification program to the interface means, 
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determining whether the output data of the hardware block input via the interface means 
is valid, and applying only the valid output data of the hardware block to the software 
block (within software debugger 2004 shown on the Fig. 21 to control execution of the 
verification program, wherein when at least one trigger condition is detected/valid output 
data, debugger 2004 halts the program execution (col. 57, II. 52-57)). 

With respect to claim 11 (as best understood) Schubert et al. teaches the 
limitations similar to claim 1 including a chip verification method for a chip design 
verification apparatus including et least one hardware block and a processing means, 
the processing means having at least one software block, a chip design verification 
program, and storage means of storing input and output data, and interface means of 
interfacing with the software block and the hardware block (within hardware/software 
co-debugging system and method shown on the Figs. 21, 33B (col. 57, 11.9-11; col. 60, 
11.17-20)). 

With respect to claim 26 (as best understood) Schubert et al. teaches a chip 
design verification method for a chip design verification apparatus including a hardware 
block and a software block having at least one function block, a chip design verification 
program for verifying operations of the software block and the hardware block, a storage 
means of storing input and output data of the software block generated by executing the 
chip design verification program, and an interface means of performing an interfacing 
operation between the hardware block and the software block (within hardware/software 
co-debugging system and method shown on the Figs. 21, 33B), the method comprising: 
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a clock generation step of allowing the chip design verification program to obtain 
a multi clock setting value to be provided to the interface means, and generate multi 
clocks in response to a system clock of the chip design verification program and the 
multi clock setting value to be applied to the software block, and allowing the interface 
means to generate multi clocks in response to the system clock of the interface means 
and the multi clock setting value to be applied to the hardware block (within the software 
DIC API 3220/interface as shown on the Fig. 33B (col. 9, II.22-26), which to interact with 
software block 2002 and hardware block DUT 102 (col. 60, 11.17-22), wherein interface 
3220 implements control data signal between DUT 102 and software 2002 (col. 59, 
II. 27-32; II.47-53) including setting trigger conditions (col. 17, II. 57-67), and wherein 
when at least one trigger condition is detected/valid output data, debugger 2004 halts 
the program execution (col. 57, II.52-57), and wherein interaction is implemented within 
the communication controller 816 shown on the Fig. 8 (col. 59, 11.10-20)); 

a software side operation step of transmitting output data generated by the 
operation of the software block operating in response to the multi clocks of the chip 
design verification program to the interface means, determining whether the output data 
of the hardware block received via the interface means is valid by executing the chip 
design verification program, and applying only the valid output data of the hardware 
block to the software block (by software block 2002 shown on the Fig. 33B, wherein 
software debugger 2004 interacts with both interface 3220 and software block 2002 
(col. 60, II. 23-24), and wherein software debugger 2004 interacts with the DIC of the 
hardware block 102 using the communication controller 816 (col. 59, 11.10-24)); and 
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a hardware side operation step of transmitting output data generated by the 
operation of the hardware block operating in response to the multi clocks of the 
interface means to the software block, determining whether the output data of the 
software block received is valid by executing the chip design verification program in the 
interface means, and applying only the valid output data of the software block to the 
hardware block (by software DIC API 3220, which controls retrieving data from 
hardware block 102 and back-annotates sampling data (col. 59, II. 27-33; 47-53)). 
Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to HELEN ROSSOSHEK whose telephone number is 
(571)272-1905. The examiner can normally be reached on 7:30-4:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jack Chiang can be reached on 571-272-7483. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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06/27/2008 



/Helen Rossoshek/ 

Primary Examiner, Art Unit 2825 



